This optimizes/streamlines fill operations.

Backstory:

• since 1.21 we have a clear builtin which is faster than copy when zeroing memory
• slices.Repeat uses a copy loop very similar to the one we're using
• bytes.Repeat does the same, but adds an 8KB maximum to the chunk size
• the existing generated code could be streamlined

Intuition:

• rare that tables are much larger than 8KB
• using clear (actually runtime.memclrNoHeapPointers) from native code is harder
• favor smaller/simpler code for tables, faster code for memory (like the standard library)

For the compiler:

• streamline/simplify table.fill
• optimize memory.fill using the 8KB maximum chunk size

For the interpreter:

• keep table.fill unchanged
• optimize memory.fill with both clear and maximum chunk size

For table.Grow:

• recognize that zero initialization is already done

Results:

I could measure an over 2x improvement filling megabytes of memory, with no degradation in performance at small sizes. No increase of generated code size.

Future work:

Using memory.fill to zero memory is very common. If we could access runtime.memclrNoHeapPointers in the compiler, we could potentially gain another 25% there (especially if we optimized this when zero is known at compile time).